\chapter{Űrlap generálás}

	Ebben a fejezetben leírom az űrlap generálásának módszerét, amely a teljes
	folyamatot jelenti a tudásbázistól a megjeleníthető űrlapig. A folyamat vizsgálata 
	során itt is külön ismertetem az online és az
	offline kitöltési módot, figyelmet fordítva a különbségeikre is.
	
	\section{Online kitöltés architektúrája}
	
		Az önálló labor keretében készített online kitöltés módszerének legfőbb
		szempontja az volt, hogy a felhasználó számára elérhetővé tegyem a
		tudásbázist felhasználó fejlettebb funkciókat, így például a származtatott
		mezők automatikus és azonnali kiszámítását a kitöltés közben és a beírt
		adatok folyamatos ellenőrzését.
		
		Ahhoz, hogy ezen funkciók működése biztosított legyen, az űrlap
		megjelenítését végző és a kitöltést vezérlő alkalmazás számára folyamatos
		kapcsolatot kell lehetővé tenni a tudásbázissal. Ez megoldható a tudásbázis
		decentralizálásával is, de egyszerűbb megoldás az űrlap megjelenítés
		alkalmazáslogikájának áthelyezése a kiszolgálóra. 
		
		Ennek megvalósításához egy egyszerű, böngészőben futtatható JavaScript
		alkalmazást hoztam létre, amely egy vékony megjelenítő rétegként működik egy
		a kiszolgálón futó alkalmazás számára. A megjelenítő réteg AJAX hívásokkal
		elküldi a felhasználói eseményeket a kiszolgálón futó alkalmazásnak, amely
		alacsony szintű parancsokkal befolyásolja a felhasználó számára megjelenített
		HTML dokumentumot.
		
		A \ref{fig:online-arch} ábrán látható, hogy a kliens-szerver architektúrát
		követve a rendszer megengedi, hogy egyszerre több felhasználó csatlakozzon és
		töltsön ki űrlapot. Minden felhasználónak elindul egy űrlap kitöltő
		alkalmazás a kiszolgálón, melyek a központi tudásbázishoz csatlakoznak az
		űrlapspecifikus műveleteket lehetővé tevő interfészen keresztül, mely az
		ábrán OWLForms kiszolgáló néven szerepel.
		
		\begin{figure}[!ht]
			\centering
			\includegraphics[width=150mm, keepaspectratio]{figures/ch6/online_arch.png}
			\caption{Online kitöltés architektúrális ábrája} 
			\label{fig:online-arch}
		\end{figure}
	
		\subsection{Kitöltés vezérlése}
		
			A felhasználó, amikor csatlakozik a kiszolgálóhoz, kiválasztja a kitölteni
			kivánt űrlapot egy listából, ami nem más, mint egy hivatkozás a
			példányosítandó osztályra a tudásbázisban. Az ezután a kiszolgálón elinduló
			alkalmazás létrehoz egy kezdetben egyedet a tudásbázisban, aminek a
			tulajdonságait fogja a felhasználó kitölteni értékekkel.
			
			Az alkalmazás ezután listázza az egyed kitölthető tulajdonságait, és a
			felhasználó böngészőjében futó megjelenítési rétegben létrehozza a megfelelő
			mezőket. A származtatott mezők is megjelennek a felhasználó előtt csak
			olvasható mezőként, de ezeknek még nincsenek értékei mivel azon mezők
			sincsenek kitöltve, melyektől függenek.
			
			Az alkalmazás inicializálása után a felhasználó megkezdheti a kitöltést a
			böngészőjében megjelenő mezők egyikébe írásával. Ha a felhasználó
			megváltoztatja az egyik mező értékét, a megjelenítő réteg egy eseményt
			képez, és elküldi a kiszolgálónak, ahol a kitöltést vezérlő program kapja
			meg. Az esemény tartalmazza, hogy melyik mezőbe milyen értéket gépelt be a
			felhasználó, ami alapján az alkalmazás kikeresi a mezőhöz tartozó
			tulajdonságot. Mindenekelőtt az alkalmazás ellenőrzi a begépelt érték
			típusát, hogy megfelel-e a tulajdonság értékkészletének, és ha hibát észlel
			(például ha hét betűs Neptun kódot adtak be, vagy szöveget írtak be számot
			tartalmazó mezőbe), akkor erről visszajelzést ad a felhasználónak. Ha az
			érték típusa rendben van, ezt az értéket betölti a korábban létrehozott
			egyed megfelelő tulajdonságába, így a beírt érték azonnal bekerül a
			tudásbázis felhasználóknak fenntartott ontológiájába. Mivel ezen ontológia
			változását a rendszer azonnal jelzi a következtetőgépnek, így amikor a
			változtatás után az alkalmazás rákérdez a származtatott mezők értékére az
			biztosan a legfrissebb adatok alapján van számolva, így az alkalmazás
			elküldheti azokat a megjelenítő rétegnek.
	
	\section{Offline kitöltés architektúrája}
		
		Az online kitöltés módszerével szemben az offline kitöltéssel megpróbálom
		csökkenteni a kiszolgálóra háruló számítási terhet azáltal, hogy a tudásbázis
		használatát igénylő funkciók használatát leválasztom a kitöltéstől azzal,
		hogy a kitöltendő űrlapot egy egyszerűbb, a felhasználónál futtatható
		eszközzel felhasználható formába, azaz egy XForms dokumentummá alakítom.
		
		A folyamat első lépéseként a rendszer egy absztrakt, űrlapok leírására
		alkalmas adatszerkezetbe gyűjti ki az űrlap adatait, így a mezők leírását,
		kötéseket a tudásbázishoz és a megjelenítés paramétereit. Ezen adatszerkezet
		eléréséhez létrehoztam egy interfészt, ami elválasztja az adatok kigyűjtését
		az XForms dokumentum létrehozásától, felosztva ezzel a feladat komplexitását.
		
		\subsection{OWLForms API}
		
			OWLForms API-nak neveztem el az interfészt, ami réteget képez az űrlap
			adatainak kigyűjtése és az űrlap dokumentum előállítása között, elrejtve
			egymás elöl a két funkció belső bonyolultságát. Az interfész egy űrlapok
			leírására alkalmas adatszerkezetet kezel, amit a tudásbázis alapján tölt fel
			a rendszer, a másik oldalon pedig ez alapján generálja az XForms
			dokumentumot.
		
			\begin{figure}[!ht]
				\centering
				\includegraphics[width=150mm,
				keepaspectratio]{figures/ch6/owlforms_api_class.png}
				\caption{Az OWLForms API egyszerűsített osztálydiagramja} 
				\label{fig:owlforms-api-class}
			\end{figure}
		
			A \ref{fig:owlforms-api-class} ábrán látható az interfészen keresztűl
			elérhető adatszerkezet leegyszerűsített osztálydiagramja. Az
			\emph{``Entity''} interfész egy URI-t tartalmaz, ami lehetővé teszi bármely 
			elem kötését a
			tudásbázishoz. Ennek leszármazottja a \emph{``Form''}, amely egy űrlapot
			reprezentál, a hozzá tartozó URI pedig az űrlap által példányosított
			osztályt azonosítja a tudásbázisban. Az űrlap tartalmaz egy listát a
			tartalmazott mezőkről (\emph{``Field''}), amely egy OWL tulajdonságra
			(\emph{Property}) hivatkozik a tudásbázisban. A mezők ezen felül információt
			adnak a mezőbe
			beírható értékek típusáról és számosságáról. A típus lehet egy XSD adattípus
			URI-vel azonosítva, vagy ha egy beágyazott űrlapról van szó, akkor a
			beágyazott űrlap által példányosított egyed URI-je.
			
			A beágyazott űrlapot tartalmazó mezők implementálják továbbá a
			\emph{``ComplexField''} interfészt is, amely hivatkozást ad a beágyazott
			űrlaphoz tartozó \emph{``Form''} objektumra.
			
			A megjelenítési
			információkat elérhetővé tevő interfészeket az áttekinthetőség kedvéért
			külön diagrammon ábrázoltam. Ezen interfészek lazán csatolódnak az űrlap
			adatszerkezetéhez, elkülönítve az űrlap szerkezetének leírásától.
		
			\begin{figure}[!ht]
				\centering
				\includegraphics[width=150mm,
				keepaspectratio]{figures/ch6/owlforms_style.png}
				\caption{Az OWLForms API megjelenítési rétegének osztálydiagramja} 
				\label{fig:owlforms-style}
			\end{figure}
		
			Ahogy a \ref{fig:owlforms-style} ábrán látható, a kimenetet megjelenítését
			befolyásoló \emph{``OWLFormsStyle''} interfészt megvalósító objektum az
			űrlapot reprezentáló \emph{``Form''} interfészhez van kötve. Ez az objektum
			reprezentálja az űrlap stílusát, ami a mezők feliratát és sorrendezését adja. 
			
			A mezők feliratát a \emph{``FieldTitleProvider''} interfészt megvalósító
			objektum adja, amelytől a \emph{getTitle} metódusán keresztűl lehet kérni egy
			nyelvfüggő feliratot egy mezőhöz. Hasonlóan egyszerű interfész végzi a mezők
			sorrendezését is, a \emph{``FieldOrderProvider''} \emph{orderFields} metódusa
			a mezők egy rendezetlen halmazából készít egy rendezett listát.
			
			Mindkét interfész egyszerű és általános módon oldja meg a feladatát,
			elrejtve a használó elöl a hívás mögött lévő számítás módját és
			komplexitását.
		
		\section{Űrlap adatainak kigyűjtése a tudásbázisból}
		
			Az űrlapot leíró adatszerkezet létrehozásához a tudásbázisból ki kell
			gyűjteni az űrlap modell és megjelenítési adatokat. A kigyűjtés belépési
			pontja az űrlap által példányosítandó osztály a tudásbázisban, amit a
			felhasználó jelöli ki a kitölthetőként megjelölt és rendelkezésre álló
			osztályok közül.
			
			Az osztály ismeretében a követketkeztetőgép ki tudja listázni az 
			osztály tulajdonságaihoz kötött számossági megkötéseket tartalmazó
			axiómákat. A tudásbázisban ilyen axióma köti össze például a
			\emph{``személy''} osztályt a \emph{``név''} tulajdonsággal, amit OWL
			megjelenítési szintaxisban a következőképpen írhatunk le: 
			
			\vspace{0.5cm}
			\code{\large{Személy név exactly 1 Literal}}
			\vspace{0.5cm}
			
			A fenti kifejezés formálisan annyit jelent, hogy ha egy X egyed része a
			\emph{``Személy''} osztálynak, akkor X egyed \emph{``név''} tulajdonságának
			pontosan egy szöveg típusú értéke van. Az űrlap szempontjából ezt úgy értelmeztem, hogy
			ha szeretnénk létrehozni egy \emph{``Személy''} osztályba tartozó X egyedet,
			akkor ahhoz a felhasználónak meg kell adni pontosan egy értéket a
			\emph{``név''} tulajdonsághoz. Azaz az űrlapon meg kell jeleníteni egy
			mezőt, ahova a felhasználó beírja a nevét. Mivel itt pontosan 
			egy értéket vár a rendszer,
			se többet, se kevesebbet, ezért ezen mező kitöltése kötelező, e nélkül az
			űrlap érvénytelen, mivel nem lehet létrehozni a \emph{``Személy''} osztálynak
			megfelelő egyedet a \emph{``név''} tulajdonság kitöltése nélkül.
			
			Ahogy a példában látható, a számossági megszorítások tartalmazzák a
			kitöltendő tulajdonságot és kijelölnek egy intervallumot a megadandó értékek
			számosságára. Az azonos tulajdonságra adott több számossági megkötés esetén
			a rendszer ezen intervallumok metszetét veszi, mivel a szemantika szerint
			az összes megkötésnek egyidejüleg teljesülnie kell.
			
			Bár a számossági megkötés ad lehetőséget a típus megkötésére is, a rendszer
			nem veszi ezt figyelembe, a tuljadonságok által kért típust a tulajdonsághoz
			értékkészlet (range) alapján határozza meg. Azért választottam ezt a
			megoldást, mert a tulajdonság az értékkészletével együtt tárgyterületi 
			modellben van definiálva, míg a számossági megkötés az űrlap modellhez
			tartozik, és a rendszer követelménye, hogy az űrlap által létrehozott 
			példány az űrlap
			modell ismerete nélkül is feldolgozható legyen.
		
			Egy számossággal megjelölt tulajdonság az űrlap absztrakt leírásában
			megfelel egy mezőnek (\ref{fig:owlforms-api-class} ábra, \emph{Field}
			osztály). Az űrlap végleges formájában azonban ez a megfeleltetés nem 
			lesz egyértelmű a
			többszörös és összetett mezők miatt. A kitölthető űrlap az
			absztrakt leírás alapján történő létrehozását a következő szakaszban
			tárgyalom részletesen.
			
			A kitöltendő mezők listázásán kívül a mezők megjelenítési adatait kell
			kigyűjteni, ami lényegesen egyszerűbb feladat, hiszen a felirat és a
			sorrendezést adó ``súly'' egyszerű annotációként jelenik meg az űrlap
			modellben. Az annotációk lekérését a következtetőgép közvetlenül támogatja,
			így ezen adatok egyszerűen átadhatóak az űrlap absztakt leírásának.
		
		\section{XForms dokumentum előállítása}
		
			Ebben a szakaszban azt a folyamatot részletezem, ahogy a rendszer az
			absztrakt űrlap leírás alapján létrehozza a felhasználó számára
			megjeleníthető és kitölthető XForms dokumentumot. Ahogy azt a 
			\ref{ch3:xforms-structure} részben is említettem, az XForms
			űrlap két részből áll, az űrlap modellből és az űrlap törzsből.
			
			\subsection{Űrlap modell}
			
			\label{ch6:form-output}
			
			Az űrlap modell lényege az XML egyed, amely a felhasználó által kitöltött
			adatokat fogja tárolni, és meghatározza az űrlap szerkezetét. Mivel a
			felhasználó által kitöltött adatokat az XML egyedben tárolva adja vissza az
			űrlap, így fontos, hogy a szerkezete lehetővé tegye a könnyű
			feldolgozhatóságot. Itt is igyekeztem a legegyszerűbb módszert választani,
			szem előtt tartva azt, hogy az űrlap kitöltése után az adatok alapján a
			rendszernek létre kell hoznia egy egyedet a tudásbázisban.
	
			Kihasználva azt, hogy az űrlap absztrakt leírás szerkezetileg követi a
			példányosítandó egyed felépítését, magától értetődik, hogy az űrlap modell
			is ugyanilyen szerkezetű legyen. Ennek a szemléltetéséhez visszatérek a
			\ref{fig:szoctam_model} ábrán lévő tudásmodellrészlethez, bemutatva, hogy
			ezen tudásbázis részlet alapján generált űrlapot kitöltve hogy nézne ki az
			űrlap kimenetét képező XML dokumentum.
			
			\begin{verbatim}
<formdata uri="http://hu.bme.sc/szoctam.owl#Szoctam_Hallgato">
   <fielddata uri="http://hu.bme.sc/szoctam.owl#nev">
      <value>Kovács János</value>
   </fielddata>
   <fielddata uri="http://hu.bme.sc/szoctam.owl#neptun">
      <value>ABC123</value>
   </fielddata>
   <fielddata uri="http://hu.bme.sc/szoctam.owl#egyforeesojovedelem">
      <value>
         <formdata uri="http://hu.bme.sc/szoctam.owl#EgyForeEsoJovedelem">
            <fielddata uri="http://hu.bme.sc/szoctam.owl#jovedelem">
               <value>44321</value>
            </fielddata>
         </formdata>
       </value>
   </fielddata>
</formdata>
            \end{verbatim}

			Ez a dokumentum egyszerű elemeket használva tárolja az adatokat, és azok
			kötését a tudásbázishoz. A \emph{``formdata''} elem reprezentálja a kitöltött
			űrlapot, a \emph{``uri''} attribútuma pedig az osztály URI-jét tartalmazza,
			ami az űrlap alapját képezi. Ehhez hasonló a \emph{``fielddata''} elem, ami
			egy tulajdonsághoz tartozó mezőbe beírt értéket vagy értékeket tárolja.
			
			Minden értéket egy \emph{``value''} elem zár körül, amely érték lehet
			egyszerű tulajdonság esetén egy szöveges érték, összetett tulajdonságnál pedig egy
			beágyazott \emph{``formdata''} elem.
			
			A fent bemutatott XML dokumentum kitöltés kezdetén nem tartalmaz értéket, de
			az alapvető szerkezetének teljesnek kell lennie, hogy az XForms
			dokumentumban mezőket lehessen kötni hozzá.
			
			\subsection{Megjelenítés}

			Az XForms szabvány az űrlap modell szerkesztéséhez definiál elemeket,
			melyeket a dokumentum törzs részében elhelyezve lehet megjeleníteni a
			felhasználónak. A legalapvetőbb elem ezek közül a szövegmező, ami egyszerű
			szöveges, vagy valamely XSD adattípusnak megfelelő adatot kér be a
			felhasználótól. A szövegmezőnek meg kell adni egy XPath kifejezésben, hogy a
			kimeneti dokumemtumfában hol tárolja a beírt adatot, továbbá megadható a
			típusa és a felirata.
			
			A fent tárgyalt példánál maradva a Neptun kódnak megfelelő
			mező a következő képpen néz ki a dokumentum törzsben:
			
			\begin{verbatim}
<input ref="/formdata[@uri='http://hu.bme.sc/szoctam.owl#Szoctam_Hallgato']/
     fielddata[@uri='http://hu.bme.sc/szoctam.owl#neptun']/value" 
     type="http://hu.bme.sc/datatypes.xsd#neptuncode">
   <label>Neptun kód</label>
</input>
            \end{verbatim}
			
			Ennek hatására a felhasználó számára megjelenik egy szövegmező a megadott
			felirattal, melybe ha egy érvényes Neptun kódot ír, az betöltődik a kimeneti
			dokumentum megfelelő helyére. A \emph{``ref''} attribútum tárolja az adat
			helyének elérési útvonalát, amely jelen esetben abszolút módon adja meg az adat
			helyét. Relatív útvonalat más elemekkel együtt lehet használni, én a
			többszörös értékű mezők, illetve a beágyazott űrlapok megjelenítéséhez
			egyaránt alkalmas \emph{``repeat''} elemet használom, ami benne foglalt
			teljes tartalmat annyiszor ismétli meg, ahány dokumentum node-ot meghatároz a
			számára megadott XPath kifejezés. Továbbá a \emph{``repeat''} elemen belül
			használt összes XPath kifejezés lehet relatív az aktuálisan listázott csomóponthoz
			képest.
	